Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.claude/skills/map-efficient/efficient-reference.md:
- Around line 128-146: The execution strategy table is inconsistent with
`select_execution_strategy()`: the `wave_mode="on"` with width-1 case should not
be labeled as wave-loop if the code still returns "sequential". Update the
`execution.wave_mode` decision row in `select_execution_strategy`’s documented
behavior so it matches the actual branch for `has_parallel_groups == False`, and
keep the guidance aligned with the `get_next_step` vs `get_wave_step` cursor
separation. Make the same wording correction in the mirrored
`efficient-reference.md` copies under `.agents/skills/map-efficient` and
`src/mapify_cli/templates/codex/skills/map-efficient`.

In `@src/mapify_cli/dependency_graph.py`:
- Around line 687-689: The guard in dependency_graph.py’s thin-edge check
contradicts the comment and still allows false positives when only one node has
io data. Update the conditional in the relevant dependency analysis logic so it
skips the edge when either side is missing io data, matching the intent
described near the `a_io`/`b_io` check and preventing `thin_edge` from being set
without full input/output evidence.

In
`@src/mapify_cli/templates_src/codex/skills/map-efficient/efficient-reference.md.jinja`:
- Around line 101-107: Update the execution-strategy table in
efficient-reference.md.jinja to match select_execution_strategy(): for
wave_mode="on" with only width-1 color groups, it should still resolve to the
legacy sequential walker unless the dispatcher explicitly switches to wave_loop.
Adjust the affected row(s) so the documented mapping for wave_mode="on" aligns
with get_next_step vs get_wave_step / validate_wave_step / advance_wave and
avoids claiming wave-loop behavior when no group has width >= 2.

In `@src/mapify_cli/templates_src/map/scripts/map_orchestrator.py.jinja`:
- Around line 2352-2354: `get_wave_step()` currently adds `concurrency_enabled`
only in the active-wave path, so the no-wave and already-complete early returns
return a different shape. Update the `get_wave_step` template in
`map_orchestrator.py.jinja` so every return branch includes
`concurrency_enabled`, using the same `WAVE_CONCURRENCY_ENABLED` value (or an
explicit false equivalent if appropriate) in the early exits as well as the main
branch, then re-render the templates.

In `@src/mapify_cli/templates_src/map/scripts/map_step_runner.py.jinja`:
- Around line 15508-15512: The worktree probe cache in the probe/result flow is
treating transient `git worktree add` failures as permanent unsupported state.
Update the logic around `_WORKTREE_PROBE_CACHE`, the `git worktree add`
handling, and the cached miss rewrite path so only successful probes are
memoized, or keep a separate create-failure status instead of mapping it to
`worktree_unsupported`. Ensure `auto` can recover after a transient failure and
`required` does not keep aborting once the repo is fixed.
- Around line 15747-15776: The managed-worktree filter in the worktree
enumeration logic is too loose because it uses a substring check on the path
string, which can misclassify unrelated worktrees as managed. Update the
candidate collection in the git worktree scan to use real resolved-path ancestry
against the storage root before adding entries to candidate_paths, and keep the
existing _wt_force_remove flow only for paths confirmed to live under the
managed storage directory.

In
`@src/mapify_cli/templates_src/skills/map-efficient/efficient-reference.md.jinja`:
- Around line 128-136: The `execution.wave_mode="on"` case for color groups of
size 1 is inconsistent with `select_execution_strategy()`. Update the table and
surrounding text in the `efficient-reference.md.jinja` template so the `on` +
all groups width-1 row maps to the sequential dispatcher, matching the logic in
`select_execution_strategy()` and the related `wave_loop`/`sequential` behavior.

In `@tests/test_map_orchestrator.py`:
- Around line 4647-4653: The select_execution_strategy test setup is overwriting
sys.modules["map_step_runner"] and then unconditionally removing it, which can
erase a preexisting module imported by other tests. Update the affected blocks
in test_map_orchestrator.py to save the previous sys.modules["map_step_runner"]
value before assigning fake_runner_off/fake_runner_on/etc., and restore that
original entry in the finally block instead of always popping it. Use the same
save/restore pattern around each temporary map_step_runner injection in the
select_execution_strategy cases.

In `@tests/test_wave_eval_harness.py`:
- Around line 18-29: The test module import setup leaves SCRIPTS_PATH inserted
on sys.path for the whole pytest session, so import order affects later imports
of map_step_runner and map_utils. Move the import logic in
tests/test_wave_eval_harness.py to a local helper or fixture using importlib,
and make sure sys.path is restored after loading the runner so the path mutation
is scoped to these tests only.

In `@tests/test_wave_fixtures.py`:
- Around line 107-117: The non_git_dir verification in
test_vc1_all_fixtures_loadable_non_git_dir unconditionally invokes git
rev-parse, which breaks the test when git is not installed. Add a
git-availability guard in this test (using the same skip behavior used elsewhere
in the fixture module) before running the subprocess, so the non_git_dir
assertion only executes when git is available.